Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/textfile/faqs/c_faq/diff

Internet Message Format | 1992-12-26 | 14.5 KB

Xref: bloom-picayune.mit.edu comp.lang.c:59948 news.answers:3846
Newsgroups: comp.lang.c,news.answers
Path: bloom-picayune.mit.edu!adam.mit.edu!scs
From: [e-mail] (Steve Summit)
Subject: comp.lang.c Changes to Answers to Frequently Asked Questions (FAQ)
Message-ID: <[e-mail]>
Followup-To: poster
Sender: [e-mail] (News system)
Supersedes: <[e-mail]>
Nntp-Posting-Host: adam.mit.edu
Reply-To: [e-mail]
X-Archive-Name: C-faq/diff
Organization: none, at the moment
Date: Tue, 3 Nov 1992 01:05:10 GMT
Approved: [e-mail]
Lines: 340

Archive-name: C-faq/diff

This article contains changes between the previous revision of
the comp.lang.c frequently-asked questions list (posted on
October 1) and the new one.  (Do _not_ worry if you have not seen
the new one yet; it's coming up next.)  As usual, these diffs
have been edited for readability, and are not suitable for use
with the patch program.

The changes this month are mostly minor and/or cosmetic.  The
only mildly significant and/or interesting one is that I had
somehow managed to add the same question twice (what had been 2.5
and 2.6); thanks to Mark Brader for pointing this out.

==========
< [Last modified October 1, 1992 by scs.]
---
> [Last modified November 2, 1992 by scs.]
==========
    pointer arguments.  To generate a null pointer in a function
<     call context, an explicit cast is typically required:
---
>     call context, an explicit cast is typically required, to force
>     the 0 to be in a pointer context:
==========
    6.    The "null string," which is another name for an empty
<         string.  The term "null string" can be confusing in C
---
>         string ("").  The term "null string" can be confusing in
==========
<     (The exceptions are when the array is the operand of a sizeof()
<     or & operator, or is a literal string initializer for a
---
>     (The exceptions are when the array is the operand of a sizeof or
>     & operator, or is a literal string initializer for a character
==========
  A:    Since arrays decay immediately into pointers, an array is never
<     actually passed to a function.  Therefore, any parameter
---
>     actually passed to a function.  As a convenience, any parameter
==========
< 2.5:    Why doesn't sizeof() properly report the size of an array that's
<     a parameter to a subroutine?
<
< A:    sizeof() reports the size of the pointer parameter which the
<     subroutine really receives (see question 2.4).
<
< 2.6:    Why doesn't sizeof(array) work when the array is a function
<     parameter?
<
< A:    The compiler pretends that the array parameter was declared as a
<     pointer (see question 2.4), and sizeof reports the size of the
<     pointer.
---
> 2.5:    Why doesn't sizeof properly report the size of an array which is
>     a parameter to a function?
>
> A:    The sizeof operator reports the size of the pointer parameter
>     which the function actually receives (see question 2.4).
==========
    no longer needed.  You must also be extremely cautious when
<     passing dynamically-allocated arrays down to other subroutines,
<     if those subroutines are also to accept conventional,
---
>     passing dynamically-allocated arrays down to other functions, if
>     those functions are also to accept conventional, statically-
==========
< 2.13:    I passed a pointer to a subroutine which initialized it:
---
> 2.12:    I passed a pointer to a function which initialized it:
==========
            static int dummy;
<             ip = &i;
---
>             ip = &dummy;
==========
< A:    Did the subroutine try to initialize the pointer itself, or just
---
> A:    Did the function try to initialize the pointer itself, or just
==========
<     value.  The called subroutine altered only the passed copy of
<     the pointer.  You'll want to pass the address of the pointer
<     (the subroutine will end up accepting a pointer-to-a-pointer).
---
>     value.  The called function altered only the passed copy of the
>     pointer.  You'll want to pass the address of the pointer (the
>     function will end up accepting a pointer-to-a-pointer).
==========
< 3.4:    I have a function that returns a string, and it seems to work
<     fine under the debugger, but when it returns to its caller, the
<     returned string is garbage.
---
> 3.4:    I have a function that is supposed to return a string, but when
>     it returns to its caller, the returned string is garbage.
==========
  A:    Under C's integral promotion rules, the multiplication is
<     carried out using integer arithmetic, and the result overflows
<     and/or is truncated before being assigned to the long int left-
---
>     carried out using int arithmetic, and the result may overflow
>     and/or be truncated before being assigned to the long int left-
==========
    "int func(x) float x;".  Old C (and ANSI C, in the absence of
<     prototypes) silently promotes floats to doubles when passing
<     them as arguments, and arranges that doubles being passed are
<     coerced back to floats if the formal parameters are declared
<     that way.
---
>     prototypes, and in variable-length argument lists) "widens"
>     certain arguments when they are passed to functions.  floats
>     are promoted to double, and characters and short integers are
>     promoted to integers.  (The values are automatically coerced
>     back to the corresponding narrower types within the body of the
>     called function, if they are declared that way there.)
==========
<     rely on such an extension?  It is usually a bad idea to try to
<     determine language properties, especially pertaining to the ANSI
<     Standard, by performing experiments with a particular compiler.
---
>     rely on such an extension?  It is usually a bad idea to perform
>     experiments with a particular compiler to determine properties
>     of a language; the applicable standard may permit variations, or
>     the compiler may be wrong.
==========
  A:    There is no good answer to this question.  If the values are
    integers, a well-known trick using exclusive-OR could perhaps be
    used, but it will not work for floating-point values or
<     pointers, (and it will not work if the two values are the same
<     variable, and the "obvious" supercompressed implementation for
<     integral types a^=b^=a^=b is, strictly speaking, illegal due to
<     multiple side-effects, and...).  If the macro is intended to be
---
>     pointers, or if the two values are the same variable (and the
>     "obvious" supercompressed implementation for integral types
>     a^=b^=a^=b is in fact illegal due to multiple side-effects,
>     and...).  If the macro is intended to be used on values of
==========
    The best all-around solution is probably to forget about using a
<     macro, unless you don't mind passing in the type as a third
---
>     macro, unless you're willing to pass in the type as a third
==========
< 6.5:    Does sizeof() work in preprocessor #if directives?
---
> 6.5:    Does the sizeof operator work in preprocessor #if directives?
==========
    compilation, before type names have been parsed.  Consider using
<     the predefined constants in <limits.h>, or a "configure" script,
---
>     the predefined constants in ANSI's <limits.h>, or a "configure"
==========
<         #include <stddef.h>        /* for NULL, size_t */
<         #include <stdlib.h>        /* for malloc */
---
>         #include <stdlib.h>        /* for malloc, NULL, size_t */
==========
    Under a pre-ANSI compiler, rewrite the function definition
    without a prototype ("char *vstrcat(first) char *first; {"),
<     include <stdio.h> rather than <stddef.h>, replace "#include
<     <stdlib.h>" with "extern char *malloc();", and use int instead
---
>     include <stdio.h> rather than <stdlib.h>, add "extern
>     char *malloc();", and use int instead of size_t.  You may also
==========
>     Remember that in variable-length argument lists, function
>     prototypes do not supply parameter type information; therefore,
>     default argument promotions apply (see question 5.6), and null
>     pointer arguments must be typed explicitly (see question 1.2).
==========
< A:    Structures may have this padding, so that alignment properties
<     will be preserved when an array of contiguous structures is
<     allocated.
---
> A:    Structures may have this padding (as well as internal padding;
>     see also question 9.5), so that alignment properties will be
>     preserved when an array of contiguous structures is allocated.
==========
< 9.10:    How can I turn off structure padding, so that I can get a struct
<     to conform to an externally-imposed storage layout?
---
> 9.10:    My compiler is leaving holes in structures, which is wasting
>     space and preventing "binary" I/O to external data files.  Can I
>     turn off the padding, or otherwise control the alignment of
>     structs?
==========
<     attempting to conform to some externally-imposted storage
---
>     attempting to conform to some externally-imposed storage layout,
==========
<     It is usually better to use fgets() to read a whole line, and
<     then use sscanf() or other string functions to pick apart the
<     line buffer.
---
>     It is usually better to use fgets to read a whole line, and
>     then use sscanf or other string functions to pick apart the line
>     buffer.  If you do use sscanf, don't forget to check the return
>     value to make sure that the expected number of items were found.
==========
<     links).  It is best to remember the names of open files yourself
<     (perhaps with a wrapper function around fopen).
---
>     links).  It is best to remember the names of files yourself when
>     you open them (perhaps with a wrapper function around fopen).
==========
< 12.7:    Each time I run my program, I get the same sequence of random
<     numbers.
---
> 12.7:    Each time I run my program, I get the same sequence of numbers
>     back from rand().
==========
  A:    You can call srand() to seed the pseudo-random number generator
<     with a more random value.  Popular random initial seeds are the
---
>     with a more random initial value.  Popular random initial seeds
==========
< A:    Try running lint first.  Many C compilers are really only half-
---
> A:    Try running lint first (perhaps with the -a, -c, -h, -p and/or
>     other options).  Many C compilers are really only half-
==========
  A:    Make sure you're linking against the correct math library.  For
<     instance, under Unix, you usually need to add -lm after the
<     source and object files when compiling/linking.
---
>     instance, under Unix, you usually need to use the -lm option at
>     the end of the command line when compiling/linking.
==========
  A:    You can #include <math.h> and use the pow() function, although
<     explicit multiplication is often better for small integral
<     exponents.
---
>     explicit multiplication is often better for small positive
>     integral exponents.
==========
  A:    BSD systems provide ftruncate(), several others supply chsize(),
    and a few may provide a (possibly undocumented) fcntl option
    F_FREESP.  Under MS-DOS, you can sometimes use
<     write(fd, (char *)NULL, 0).  However, but there is no truly
<     portable solution.
---
>     write(fd, "x", 0).  However, there is no truly portable
>     solution.
==========
< 17.3:    How can I return several values from a subroutine?
---
> 17.3:    How can I return several values from a function?
==========
< A:    Either pass pointers which the subroutine can fill in, or have
<     the subroutine return a structure containing the desired values.
---
> A:    Either pass pointers to locations which the function can fill
>     in, or have the function return a structure containing the
==========
< 17.7:    Does anyone know of a program for converting Pascal (FORTRAN,
<     LISP, "Old" C, ...) to C?
---
> 17.7:    Does anyone know of a program for converting Pascal or FORTRAN
>     (or LISP, Ada, AWK, "Old" C, ...) to C?
==========
<     A PL/M to C converter was posted to alt.sources in April, 1991.
<
<     The following companies sell various translation tools and
<     services:
<
<         Cobalt Blue
<         2940 Union Ave., Suite C
<         San Jose, CA  95124  USA
<         ([phone]
<
<         Promula Development Corp.
<         3620 N. High St., Suite 301
<         Columbus, OH  43214  USA
<         ([phone]
<
<         Micro-Processor Services Inc.
<         92 Stone Hurst Lane
<         Dix Hills, NY  11746  USA
<         ([phone]
---
>     This FAQ list's maintainer also has available a list of other
>     commercial translation products, and some for more obscure
>     languages.
==========
  A:    The contest typically runs from early March through mid-May.  To
    obtain a current copy of the rules and other information, send
    e-mail with the Subject: line "send rules" to:

<         {apple,pyramid,sun,uunet}!hoptoad!judges  or  [e-mail]
---
>         {apple,pyramid,sun,uunet}!hoptoad!obfuscate  or
>         [e-mail]
==========
  A:    Use arrays of char or int, with a few macros to access the right
<     bit at the right index:
---
>     bit at the right index (try using 8 for CHAR_BIT if you don't
>     have <limits.h>):
==========
<         #define Mask(bit) (1 << ((bit) % CHAR_BIT))
<         #define Slot(bit) ((bit) / CHAR_BIT)
<         #define Set(ary, bit) ((ary)[Slot(bit)] |= Mask(bit))
<         #define Test(ary, bit) ((ary)[Slot(bit)] & Mask(bit))
---
>         #define BITMASK(bit) (1 << ((bit) % CHAR_BIT))
>         #define BITSLOT(bit) ((bit) / CHAR_BIT)
>         #define BITSET(ary, bit) ((ary)[BITSLOT(bit)] |= BITMASK(bit))
>         #define BITTEST(ary, bit) ((ary)[BITSLOT(bit)] & BITMASK(bit))
==========
> 17.19: How do you pronounce "char"?
>
> A:    You can pronounce the C keyword "char" in at least three ways:
>     like the English words "char," "care," or "car;" the choice is
>     arbitrary.
==========
> Knuth    Donald E. Knuth, The Art of Computer Programming, (3 vols.),
>     Addison Wesley, 1981.
==========
  Thanks to Jamshid Afshar, Sudheer Apte, Dan Bernstein, Stan Brown, Joe
  Buehler, Burkhard Burow, D'Arcy J.M. Cain, Raymond Chen, Christopher
  Calabrese, James Davies, Norm Diamond, Ray Dunn, Stephen M. Dunn, Bjorn
  Engsig, Dave Gillespie, Samuel Goldstein, Alasdair Grant, Ron Guilmette,
  Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, Jos Horsmeier, Blair
  Houghton, Kirk Johnson, Peter Klausler, Andrew Koenig, Tom Koenig, John
> Lauro, Don Libes, Christopher Lott, Tim McDaniel, Evan Manning, Barry
> Margolin, Mark Moraes, Darren Morby, Richard A. O'Keefe, Hans Olsson,
  Francois Pinard, randall@virginia, Pat Rankin, Rich Salz, Chip
  Salzenberg, Paul Sand, Doug Schmidt, Patricia Shanahan, Peter da Silva,
  Joshua Simons, Henry Spencer, Erik Talvola, Clarke Thatcher, Chris
  Torek, Goran Uddeborg, Wietse Venema, Ed Vielmetti, Larry Virden, Freek
  Wiedijk, and Dave Wolverton, who have contributed, directly or
  indirectly, to this article.  Special thanks to Karl Heuer, and
  particularly to Mark Brader, who (to borrow a line from Steve Johnson)
  have goaded me beyond my inclination, and occasionally beyond my
  endurance, in relentless pursuit of a better FAQ list.
==========

                    Steve Summit
                    [e-mail]
                    [e-mail]
                    mit-eddie!adam.mit.edu!scs